1. Field of the Invention
The invention generally relates to a method and apparatus for transmitting data packets over an unreliable channel, and in particular to transmitting data packets having compressed headers.
2. Description of the Related Art
Several communication technologies exist for transmitting data from one terminal to another terminal. The most commonly used techniques are cellular telephony and the Internet. Further developments are media-on-demand and conversational services such as Internet telephony. Most of these services require the transport of real-time data including audio and video contents.
The Real-time Transport Protocol (RTP) provides means for such purposes. RTP is an Internet protocol for transmitting data real-time or nearly real-time. RTP itself does not guarantee real-time delivery of data but it does provide mechanisms for the sending and receiving applications to support streaming data. Typically, RTP runs on top of the UDP protocol. UDP (User Datagram Protocol) is a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides no error recovery services, but instead offers a direct way to send and receive datagrams over IP network.
While RTP has been developed for fixed networks, it may nevertheless be used in mobile networks. However, one problem in using RTP over mobile networks is the limited bandwidth in the mobile channel. This is because each of the protocols RTP, UDP and IP has its own header. A packet will then, in addition to link layer framing, have an IP header of 20 bytes, a UDP header of 8 bytes, and an RTP header of 12 bytes, thus summing up to at least 40 bytes.
This header is highly redundant, and to decrease the amount of overhead, header compression mechanisms have been developed. Header compression protocols remove the redundancy of the header and encode the information in an efficient way. This may lead to a compression of the original header down to one byte in the best case.
A system using a header compression protocol is illustrated in FIG. 1. The transmitter comprises a compressor 100 which is used for compressing the original header. The compressed header is then transmitted to the receiver and is there decompressed by the decompressor 110.
The context 120 is the state which the compressor uses to compress the header. The context is a set of variables and consists basically of an uncompressed version of the header fields of the last header. Besides the actual header fields, the context comprises additional variables, such as first order differences of header fields that have been detected to be constant for a series of successive packets. The context can also contain additional information describing the packet stream, for example the typical inter-packet increase in sequence numbers or timestamps.
In operation, the compressor 100 and the decompressor 110 are required to maintain a common context. When the context 130 of the decompressor 110 is not consistent with the context 120 of the compressor 100, header decompression will fail. This situation can occur when data packets are transmitted over unreliable, e.g. wireless, channels because packets may then be lost or damaged between compressor 100 and decompressor 110.
It is therefore necessary to initiate a resynchronization procedure once the context 130 of the decompressor 110 has become invalid. For this purpose, update (UP) packets are provided for transmitting information contained in the context 120 of the compressor 100, to the decompressor 110. Thus, by using UP packets, the context 130 is updated.
The performance of a header compression scheme can be described with two parameters, compression efficiency and robustness. A robust scheme tolerates errors on the link over which header compression takes place without losing additional packets, introducing additional errors or using more bandwidth. Using UP packets increases on the one hand the robustness, but decreases compression efficiency, since UP packets are large in size. Therefore, in addition to UP packet, non-update (NUP) packets are used which are very small and which only depend on the previous UP packet. Thus, NUP packets do not update the context so that, if a NUP packet gets lost, the context 130 of the decompressor 110 continues to be valid, so that the receiver is still able to decompress the following packets.
The packet stream to be compressed usually behaves very regularly. Most of the header fields are constant and do not change during the life-time of the stream. Some fields do change with each packet (e.g. sequence number and timestamp). If the values of these fields are synchronized to the sequence number and thus can be calculated from this number the stream is regular. Irregularities in these fields disturb this synchronization, e.g. because of a non-linear jump in the RTP-timestamp field. With an irregularity it is not possible to calculate the values of the changed fields from the sequence number. These irregularities might occur quite frequently, e.g. on the average every second for a conversational audio stream.
The length of NUP packets increases with time due to two reasons. If the stream shows irregularities the NUP packets that would be sent are larger, because these irregularities have to be included. If no irregularities in the stream occur, the length of the NUP packets also might increase with time, because of larger differences to the last update packets. To reduce the length of the NUP packets an update has to be performed, i.e. a number of UP packets are sent and if correctly received the context is updated.
One difficulty is to determine the number of UP packets to be sent for an update. If too many are sent, the context would already be updated and valid, while UP packets are still sent. This unnecessarily increases the transmitted bits and decreases the efficiency, because the UP packets are larger than NUP packets. On the other hand if not enough UP packets are sent the risk of losing the context is increased, because the probability increases that none of the sent UP packets is received.
Consequently, when the number of UP packets is too high, compression efficiency is reduced. If the number of UP packets is too low, the decompressor might lose its context so that all packets have to be discarded until the next UP packet is received correctly.
In unreliable channels, such as wireless networks, the channel quality usually varies considerably. This will now be illustrated in more detail with reference to FIGS. 2a to 2c. 
In these examples, it is assumed that a burst error occurs. Burst errors are those errors by which several successive packets get lost. In the examples of FIGS. 2a to 2c, three packets are assumed to get lost. Referring to FIG. 2a, one UP packet and two NUP packets cannot be received by the decompressor. Since the decompressor now has an invalid context, the following NUP packets have to be discarded so that there is a total loss of nine packets at the receiver.
In FIG. 2b, the number of consecutive UP packets has been increased to the amount of three. While sending a number of consecutive UP packets is usually more reliable because the probability that at least one of these UP packets is received correctly is quite high, the compression efficiency is decreased. Moreover, in the example of FIG. 2b, the robustness has in fact not been improved, since due to the nature of the burst error, again nine packets cannot be decompressed at the receiver.
One approach to overcome the problems of burst errors is to use a sparse mode, as illustrated in FIG. 2c. Using a sparse mode means that in a fixed order, UP and NUP packets are sent, so that sending all UP packets in a row is avoided. In the example of FIG. 2c, this sequence is UP-NUP-UP-NUP-NUP-UP-NUP-NUP-NUP-UP-NUP- . . . As can be seen from FIG. 2c, even transmitting packets in the sparse mode might lead to a significant loss of data packets.
Thus, the prior art techniques cannot properly deal with both compression efficiency and robustness. Instead, it has been found that it is a severe problem to determine the optimum conditions.